1. Field of the Invention
This invention relates to data transfer processing systems and, more particularly, to a system and method for flow control within stateful protocol processing and other systems.
2. Background and Benefits of the Invention
Data transfer systems typically convey data through a variety of layers, each performing different types of processing. The number of different layers, and their attributes, vary according to the conceptual model followed by a given communication system. Examples include a model having seven layers that is defined by the International Standards Organization (ISO) for Open Systems Interconnection (OSI), and a five-layer model defined by the American National Standards Institute (ANSI) that may be referred to as the “Fibre Channel” model. Many other models have been proposed that have varying numbers of layers, which perform somewhat different functions. In most data communication systems, layers range from a physical layer, via which signals containing data are transmitted and received, to an application layer, via which high-level programs and processes share information. In most of the conceptual layer models, a Transport Layer exists between these extremes. Within such transport layers, functions are performed that are needed to coordinate the transfer of data, which may have been sent over diverse physical links, for distribution to higher-level processes.
Within the transport layer, a communication system coordinates numerous messages (such as packets) that each belong to a particular “flow” or grouping of such messages. Each message may be identified by its association with a particular flow identification key (flow key), which in turn is typically defined by information about the endpoints of the communication. Transport layer processing is generally performed by processing modules which will be referred to as transport layer terminations (TLTs), which manage data received from remote TLTs (or being transmitted to the remote TLTs) according to a set of rules defined by the transport layer protocol (TLP) selected for each particular flow. A TLT examines each message that it processes for information relevant to a flowstate that defines the status of the flow to which the message belongs, updates the flowstate accordingly, and reconstitutes raw received data on the basis of the flowstate into proper form for the message destination, which is typically either a remote TLT or a local host. Flows are typically bidirectional communications, so a TLT receiving messages belonging to a particular flow from a remote TLT will generally also send messages belonging to the same flow to the remote TLT. Management of entire flows according to selected TLPs by maintaining corresponding flowstates distinguishes transport layer processing from link level processing, which is generally concerned only with individual messages.
There are many well-known TLPs, such as Fibre Channel, SCTP, UDP and TCP, and more will likely be developed in the future. TLPs typically function to ensure comprehensible and accurate communication of information to a target, such as by detecting and requesting retransmission of lost or damaged messages, reorganizing various messages of a flow into an intended order, and/or providing pertinent facts about the communication to the target. Transmission Control Protocol (TCP) is probably the best-known example of a TLP, and is extensively used in networks such as the Internet and Ethernet applications. TCP is a connection-oriented protocol, and information about the state of the connection must be maintained at the connection endpoints (terminations) while the connection is active. The connection state information includes, for example, congestion control information, timers to determine whether packets should be resent, acknowledgement information, and connection identification information including source and destination identification and open/closed status. Each active TCP connection thus has a unique connection ID and a connection state. A TCP “connection” is an example of the more general TLP concept that is termed “flow” herein, while TCP “connection ID” and “connection state” are examples of the more general TLP concepts referred to herein as “flow key” and “flowstate,” respectively. The flow key may be uniquely specified by a combination of the remote link (destination) address (typically an Internet Protocol or “IP” address), the remote (destination) TCP port number, the local link (source) address (also typically an IP address), the local (source) TCP port number, and in some cases a receiver interface ID. It may also be useful to include a protocol indication as part of the general flow key, in order to distinguish flows that have otherwise identical addressing but use different TLPs.
TCP has flow control mechanisms operative at the peer nodes of a connection to limit the rate at which a given node will emit data, but does not inherently employ explicit data rate control. A principal flow control mechanism utilized by TCP is a “sliding window”, which corresponds to range of bytes beyond the last byte acknowledged by the destination TCP peer. Flow control is effected by the sliding window by limiting the number of data packets which may be transmitted by a source TCP node prior to receipt of the next acknowledgement from the destination TCP peer.
Although the flow control processes inherent to TCP are useful in regulating data flow over the connection between a pair of TCP peers, such processes are generally inapplicable outside of the context of such a connection (e.g., between a TCP peer and an external application). Since the speed of a TCP node will never be identically matched to that of an external application in which it is in communication, it would be desirable to provide flow control mechanisms suitable for use in this context as well.